How websites were themed before

Almost always Web Designers have to know at least some internals about the templating system if they want to deliver a complete theme, ready to integrate in the particular Content Management System. Often, Web Developers have then to touch the templates again to fit to their and the CMS needs. But most of the time a static HTML template is created by a Web Designer which has to be transformed by a Web Developer to the template language in use.

The only things left to the Web Designer for easy modification are the CSS files. If the Web Designer has no access to the project's development repository, the Web Developer has again to integrate them. In the case of Plone, there is the portal_skins/custom folder which allows theme updates through the web - but all of these cases aren't optimal.

And then there was Deliverance

With Deliverance a revolutionary web design workflow was introduced.

PyPi says: "Deliverance does transformations of HTML to 'theme' pages, similar in function to XSLT but using a simpler XML-based language to express the transformation." [3]

Okay, we could have used XSLT before and besides to the Deliverance development team many kudos also have to go to those XML heads. But i hardly know someone who uses XSLT for theming websites. XSLT alone cant make the design workflow much easier as it is.

With deliverance we create a file where we express transformation rules which define how content-bits from the source HTML (which comes from the CMS system) should replace specific tags or their contents in a target theme (which is the static HTML template) - all in an easily understandable XML syntax. All elements from source and target are selectable via CSS selectors or XPath expressions. The target HTML template should be tagged with id- or class attributes, so that the relevant elements can be easily accessed via CSS selectors.

This allows empowers Web Designers to constantly improve their theme as long as they respect the Deliverance rules which modify their template on the fly.

For more information about writing rules read the Deliverance documentation [4].

Now everything with Dropbox

Dropbox [5] is a commercial file sharing provider which offers 2GB space in the cloud for free. The cool thing with Dropbox is, that it provides a client program which creates a folder in your home directory where local copies of the files from your online Dropbox folder are stored. You can edit those files or create new ones and the changes are immediately pushed to the server - and in the case of a shared folder to all subscribers of that folder. Dropbox also comes with basic versioning support.

The uncool thing with Dropbox is, that the protocol and Dropbox daemon are closed source. The other parts of the Dropbox client are open sourced, at least for Linux.

If the static HTML template is developed in an shared Dropbox folder and integrated into Deliverance via a symlink, all changes to the templates are immediately visible by all developers with that setup - normally within 5 seconds.

And because the need for design changes don't stop with website deployment, this setup can also be used for a live server. All involved parties just have to be aware about the risk of breaking the site if a modified HTML structure interferes with the Dropbox rules. But this allows Web Designers to tweak the design independently of Web developers. And this is cool.

This technique was used for the new website of Grüne Akademie Steiermark [6]. A simmilar setup without Dropbox integration on the server was first used for the Gnome WGO project [7].

Some tips when using Dropbox in your buildout environment

Let's say, the static HTML templates are developed in this folder:

/home/USER/Dropbox/website-template

and Deliverance expects it's template-directory here:

/home/USER/dev/website-buildout/static

To use the Dropbox templates with deliverance, just link the directory like so:

ln -s /home/USER/Dropbox/website-template /home/USER/dev/website-buildout/static

If you don't want to use Dropbox on your live server - for what some heavy reasons can be found - you can check in the files into your favorite Version Control System. Since you may want to check in all the files and not only the symlink, you may have to mount the Dropbox folder instead of linking it:

mount --bind /home/USER/Dropbox/website-template /home/USER/dev/website-buildout/static

Attention: Don't delete your website-buildout directory because this would also delete the Dropbox folder! You have to unmount it before or use the '-o ro' mount option for read only access.

References

• [1] http://www.coactivate.org/projects/deliverance/introduction
• [2] http://en.wikipedia.org/wiki/Dropbox_%28storage_provider%29
• [3] http://pypi.python.org/pypi/Deliverance/
• [4] http://deliverance.openplans.org/
• [5] https://www.dropbox.com
• [6] http://gruene-akademie.at/
• [7] http://svn.plone.org/svn/collective/gnomeweb-plone/
  

BlueDynamics Alliance is at Plone Conference in Budapest! Peter Holzer, Robert Niederreiter and me, Jens Klein. Also Johannes Raggam, our intern from last year is here.

Its good to meet all the people from Plone Community. Amazing how many new people are here!

We are listing to some interesting talks and if theres no we started to sprint on AGX, the framework for tree-transformations which is the base of the new (Code-) Generator.

I prepared a lighting talk on cornerstone.soup, our lightweight isolated conatainer for queryable records - based on ZTKand made for Plone.

Robert prepared a lightning talk about AGX. Johannes will show the outcome of his thesis, a "activity model runtime engine for python" - which uses AGX and the underlying zodict-Node.